Since proofs contracts are now MCP-compatible, won't there be a 1:1 mapping between game type and implementation address, so we can remove the implementation arg?

What do you think about preserving addGameType and updatePrestates as convenience functions? We often want to do just those actions (e.g. changing prestate for a hard fork) and it feels error prone and hard to review to pass a full Config into upgrade for that. These convenience functions would just gather the other inputs before calling upgrade

Who needs to do state diff review—all signers, or just the devs creating the superchain-ops task?

I feel like an easy way to mitigate this is by not changing any external function signatures until the very end

Do we want to specify prestate and gather everything up here or should we just take gameType, implementation and gameArgs to match the DisputeGameFactory.setImplementation constructor?

There's no requirement that a game type has exactly 1 prestate or that it be the only input to that type. The permissioned game probably shouldn't have a prestate at all and ZK may wind up needing more than one "prestate". Really the idea of a "prestate" only applies to the bisection process of FDG - it is the agreed state prior to the start of what's being bisected.

From discussion: OPCM still only supports a fixed set of game types and knows how to convert from the particular config for that game type (which can be customised for it) to the game args needed (mixing in addresses for things like DelayedWETH etc).

For upgrade we'd clear the initialised slot, for deploy we'd create the proxy right?

How do we plan to do this generation? We've been trying to move away from the Geth codegen tool because it creates some pretty awful code and is quite limiting in how you can actually make calls.

We've also seen issues where the struct definition is updated but the new fields aren't actually populated. We have some static analysis for this in op-deployer now but worth thinking about how we can ensure we get compiler errors if things are out of sync (including verifying the code was regenerated when required).

Is this deploying proxies only or also the implementation contracts? ie do we still depend on op-deployer boostrap implementations to actually deploy the implementation contracts?

How is this expressed in code? How do you know what you need to provide when calling upgrade? The ABIs above pass the same Config object to both deploy and upgrade so it seems unclear how to know if an upgrade requires a new setting be specified or not.

Note that there isn't a way to iterate through the list of set dispute game implementations (it's a map). Apart from migrating to interop, OPCM doesn't support removing game types, but it's worth noting that upgrade won't remove existing game types if they aren't in the games array. That feels a little more surprising with this ABI but I don't think it's unreasonable.

You can remove games by directly calling DisputeGameFactory.setImplementation and setting a 0x00 implementation address.

Actually the same thing applies to any maps set as part of initialize methods. That could open up some foot guns because map entries get left around after an upgrade and we don't have a way to specify that they should be removed.

From discussion: For game types, we have a fixed list that is supported so they can just be removed upfront and then re-add what is specified to make this work.

For the generic case we should ensure that initialisers only set simple fields and don't write to maps so they are safe to call repeatedly.

If we add a new field/change an existing field on the Config struct, won't we still have to update OP Deployer to plumb that field through the intent and into the OPCM? Is the idea that the codegen would make this process easier?

We need somebody from platforms as well to make sure it'll integrate well with deployer.

Does this include deploying blueprints?

Does this include the Superchain contracts? How do we upgrade those?